home *** CD-ROM | disk | FTP | other *** search
/ Stone Design / Stone Design.iso / Stone_Friends / Wave / WavesWorld / Source / Shaders / README < prev   
Encoding:
Text File  |  1995-03-22  |  4.2 KB  |  82 lines
  1. Some notes on shaders:
  2.  
  3.  
  4. Shaders are what make RenderMan renderers different and so much cooler
  5. (i.e. powerful and flexible) than other renderers.  Unfortunately,
  6. while writing shaders is not really hard, getting to the point where
  7. you can write shaders *is* difficult.  You don't quite have to have
  8. the equivalent of a MS in Computer Graphics to do it, but it gets
  9. close.  A real short cut to learning how to write shaders, though, is
  10. access to good shader source code.  For a long time, the only source
  11. of shader source code was the examples in the RenderMan Companion.
  12. These are nice, but it's not clear (a priori) if these are "toy"
  13. examples, and also, it's always nice to see how a bunch of different
  14. people do similar things.
  15.  
  16. In the past few months, though, this paucity of shader source has
  17. started to change.  With the advent of Larry Gritz's shareware
  18. RenderMan compliant rendering toolkit, the "Blue Moon Rendering
  19. Tools", and the release of the book "Texturing and Modeling: a
  20. Procedural Approach", which cleaned up information from a few SIGGRAPH
  21. courses and made it generally available, there is now a ready source
  22. of lots of shader code to start hacking with.  
  23.  
  24. Wannabe graphics hackers using NEXTSTEP have a great leg up here,
  25. since you've now got the best of both worlds; the superior tools and
  26. enviroment of NEXTSTEP to play, and now a wider market for you to
  27. share your work (i.e. other UNIX boxes can now compile and run your
  28. shader code using the Blue Moon tools).
  29.  
  30. I've gathered together a large amount of shader source code here in
  31. one place to use as a starting point from which WavesWorld hackers can
  32. draw from.  Feel free to use the code in here, but make sure you
  33. prominently mention who wrote the shader you started with; it's only
  34. good manners, especially since no one writes a shader from scratch (at
  35. least no one I know).
  36.  
  37. An important note on naming: shader name space, especially when you
  38. have lots of them, can get very cluttered (i.e. plastic1, myPlastic,
  39. brick, glass, grid, etc.)  One partial solution to this is to write
  40. more and more general shaders and shove the namespace problem on to
  41. the parameters; i.e. you have more and more parameters on the shaders,
  42. cutting down on the number of shaders because you have 5 that do the
  43. work formerly done by 30, but that's only a partial solution,
  44. especially when you just need to bang one out...  The other problem is
  45. that there are certain problems (tiles, bricks, wallpaper, metals,
  46. etc.) that different people approach slightly differently. When both
  47. solutions are good (sometime for different problems; one might be
  48. better, but runs slower, etc.), and you want to keep both around.
  49.  
  50. To combat this, I've tried to use consistent prefixes that correspond
  51. to the original source of the shader: DP for Darwyn Peachey, LG for
  52. Larry Gritz, BM for ones Larry distributes with the Blue Moon
  53. Rendering Tools, KM for Ken Musgrave, RC for RenderMan Companion, etc.  
  54.  
  55. This seems like a reasonable solution. A better one would also
  56. encompass some sort of "dictionary" for shader names and parameters,
  57. but that will have to wait until we have a critical mass of people on
  58. the net who want to share shaders.  I'll be happy when we get to the
  59. point of having this problem...
  60.  
  61.  
  62. Compiling these shaders:
  63.  
  64. In my environment, I have both Larry Gritz's Blue Moon Rendering Tools
  65. installed and the normal RenderMan distribution that comes with
  66. NEXTSTEP.  Larry purposely uses a different suffix (.so vs. prman's
  67. .slo) for shaders compiled with his shader compiler.  This has the
  68. happy circumstance of easily allowing both shaders to coexist in the
  69. same directory.  Unfortunately, I couldn't come up with a standard
  70. Makefile that I was happy with that, with a run-time flag, could
  71. switch rules and generate compile shaders with both shader compilers.
  72. I'm hoping someone will read this and send me one, actually :-).  In
  73. the meantime, I wrote a stupid little shell script which compiles them
  74. all and moves the shader object code into /LocalLibrary/Shaders, where
  75. they belong.  All you have to do is type "./doIt" in this directory
  76. and it will go and compile all the shader source.  It's a lame-o
  77. method, I know, but I've got bigger fish to fry, and if it bothers you
  78. that much, send me a better fix; maybe I'll use it.
  79.  
  80.  
  81. - wave
  82.